Contact UPDATE Request

Function

This request is used to update the data of an existing Contact.

Requirements

This request can only be executed if the Contact already exists.

Features

• Mandatory fields must always be filled in, even if they remain unchanged.
• Omitting any keywords when applying the key/value format has the effect of deleting the values previously set for them.
• If a Contact is used as Holder in a domain which has a DISPUTE entry placed on it, you cannot use the UPDATE request to change all of its data. Name, organization, address, postal code, city and country cannot be updated. The RegAcc must contact Business Services to have the changes implemented.

Verification

• Verification information is added, changed or removed from an existing contact of the type PERSON or ORG.

• Verification information can be deleted by not providing any information during an update.

• A Contact UPDATE request triggers a new verification process for a domain, and the syntax and completeness check and risk assessment are carried out again.

• The contact handles of the domain portfolio are not systematically scanned to determine a risk assessment for all domains. This does not apply to event-driven reviews of individual portfolio domains.

• Should an event-driven review reveal a suspicious or very high risk, a verification must be carried out as part of a domain request, which means an update of the contact.

• Verification information can also be created or modified for a contact for a domain that is subject to a DISPUTE procedure.

Contact Type

DThe contact type can be changed with an UPDATE:

• from PERSON to ORG or

• from ORG to PERSON.

Request Parameters

A Contact UPDATE request is composed of the "Contact" data object fields and some other parameters, which are described below:

Common Mistakes

The Contact handle stated in the request does not exist.

Examples

Example requests for PERSON or ORG

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Action: UPDATE
Version: 5.0
Handle: DENIC-1000002-MAX
Type: Person
Name: Max Mustermann
Organisation: DENIC eG
Address: Business Services
Address: Theodor-Stern-Kai 1
Address: The maximum number of
Address: address lines is five and
Address: one line may be 255 characters long.
PostalCode:    60596
City: Frankfurt am Main
CountryCode: DE
eMail: email-1@denic.de
eMail: email-2@denic.de
eMail: email-3@denic.de
eMail: email-4@denic.de
eMail: email-5@denic.de
eMail: email-6@denic.de
Phone: +49.6927235x290

[VerificationInformation]
VerifiedClaim: name
VerifiedClaim: address
VerificationResult: success
VerificationReference: ABC123/45GHT
VerificationTimestamp: 2023-11-11T15:36:21+02:00
VerificationEvidence: idcard
VerificationMethod: auth
TrustFramework: de_denic

[VerificationInformation]
VerifiedClaim: email
VerificationResult: failed
VerificationReference: 354546TZQ
VerificationTimestamp: 2023-10-04T12:22:19+02:00
VerificationEvidence: transaction_log
VerificationMethod: auth
TrustFramework: de_denic

1
2
3
4
5
6
7
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 
<registry-request xmlns="http://registry.denic.de/global/5.0" xmlns:contact="http://registry.denic.de/contact/5.0" xmlns:verification="http://registry.denic.de/verification/5.0">
  <contact:update>
    <contact:handle>DENIC-1000002-MAX</contact:handle>
    <contact:type>PERSON</contact:type>
    <contact:name>Max Mustermann</contact:name>

The structure in the XML document after “contact:name” is identical to the structure of a request using the RRI protocol 4.0 and can be adopted from there.

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    <verification:verificationInformation xsi:type="verification:verificationInformationType">
      <verification:verifiedClaims>
        <verification:claim>name</verification:claim>
        <verification:claim>address</verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>success</verification:verificationResult>
      <verification:verificationReference>ABC123/45GHT</verification:verificationReference>
      <verification:verificationTimestamp>2023-11-11T15:36:21+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>idcard</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>de_aml</verification:trustFramework>
    </verification:verificationInformation>
    <verification:verificationInformation xsi:type="verification:verificationInformationType">
      <verification:verifiedClaims>
        </verification:claim>email<verification:claim>
      </verification:verifiedClaims>
      <verification:verificationResult>failed</verification:verificationResult>
      <verification:verificationReference>354546TZQ</verification:verificationReference>
      <verification:verificationTimestamp>2023-10-04T12:22:19+00:00</verification:verificationTimestamp>
      <verification:verificationEvidence>transaction_log</verification:verificationEvidence>
      <verification:verificationMethod>auth</verification:verificationMethod>
      <verification:trustFramework>eidas</verification:trustFramework>
    </verification:verificationInformation>

The structure in the XML document above “contact:update” is identical to the structure of a request using the RRI protocol 4.0 and can be adopted from there.

31
32
33
  </contact:update>
  <ctid>cba-987654321</ctid>
</registry-request>

Data object PERSON and ORG

Data object REQUEST